Education of Software Engineers1

As I was reading the New York Times at the end of 2010, the headline of a news article suddenly hit me “A Pinpoint Beam Strays Invisibly, Harming Instead of Healing – A Radiation Setting Is Wrong, and Patients are Harmed” while undergoing SRS (stereotactic radiosurgery) treatment in a hospital. As American baseball player Yogi Berra once said “It’s déjà vu all over again.” When the story first appeared, it was not clear if the cause was software-related, but it sure read a lot like the Therac-25 disaster of the mid-1980s [1]. The Therac-25 was an earlier medical device where some patients were given fatal instead of therapeutic doses of radiation. A short time later I did read that the problem was in the programming of the SRS machine and involved passing information among 3 incompatible computers [2]. We apparently never learn. In the case of the Therac-25, the problem was that the erase character key was not handled correctly, so if the code to switch between radiation and x-ray treatment was typed incorrectly and the backspace key was depressed, the machine would go into the wrong state. However, the real message of the Therac-25 was not that there was a software bug. Those happen all the time in programs and are generally fixed. However, in this case the software engineers designing the Therac-25 missed a key engineering principle in designing that device. Any competent designer should be able to build software that detects a failure and either corrects it or responds in a safe manner. Fault detection and correction is standard fare for a competent software tester. The problem with the Therac-25 was that a single error was compounded with a second error. That is, the error in switching between radiation and x-ray modes was compounded by the error in the backspace key. The device was not designed to handle multiple points of failure.